在介紹完資料處理、資料搜尋、模型建立與部署之後，終於進入到最後一個環節——監控模型表現啦！

我們在前面有介紹過什麼是 data drift，以及他所帶來的問題。簡單來說，data drift 是指模型的輸入特徵隨著時間而變化，進而造成模型的表現退步。而模型效能下降不僅會影響客戶體驗，甚至會導致嚴重的盈利損失。另外，除了 data drift，另一個嚴重的問題是沒有搜集到必要的資料，造成資料損失。

因此，我們有介紹過 ml 生命週期的第五步驟即是「建造監控系統」，透過不斷地自動監控，及早發現有問題的資料，才能夠避免問題的發生。

我們今天來看看 Uber 的慘痛經驗，以及他們是如何提出解法的，讓我們以此借鏡吧。

Uber 的經驗

Uber 在計算每趟行程的車資時，曾經因為資料品質的問題，進而影響其機器學習模型的準確性，導致車資計算錯誤以及營收損失。

Uber 在計算車資時會考慮到多種因素，包含過路費、路程距離、時間等等。若在訓練模型時，有任何資料缺失，代表模型在訓練時完全沒有看過那種類型的資料，一定會影響模型的判斷，造成最後的預測失準。

很不幸地，他們曾經因為 app 記錄資料的方式改變，導致資料科學家蒐集到的資料集中，竟然缺乏美國關鍵地區中 10% 的資料。這是相當嚴重的損失，但他們非但沒有察覺，甚至使用這個缺失的資料集以訓練模型，最終誤導模型，導致錯誤的車資計算，進而造成營收損失，直到 45 天之後，才由一位資料科學家發現這個慘況。

Uber 的模擬顯示，如果 30% 的車資資料出現問題，可能會導致增量總預訂量下降 0.23%。而這次的 10% 資料損失，造成營收喪失上百萬美金。

資料損失的可能原因以及問題

經過這次教訓，Uber 嚴陣看待資料損失的問題，他們認為以下兩點是造成資料損失的主因：

• 資料不準確：app 推出新功能、data pipeline 的 ETL 邏輯改變、上游服務中斷或遷移、第三方資料來源的品質問題等，都可能導致資料不準確。
• 資料延遲：由於資料延遲，導致用於訓練模型的資料無法反應最新的市場狀況，進而影響車資計算的準確性。

資料延遲是一個非常嚴重，又很常遇到的問題，我們之前也有聊過 Netflix 和 Spotify 是如何處理的。

而這些資料問題會造成以下的影響：

• 營收損失：資料品質問題會影響車資的計算，如上面所述，延遲 45 天發現，竟然就造成營收喪失上百萬美金。
• 決策失誤：領導階層和全球營運部門會使用車資資料來做出重要決策，但是由於車資計算失準，會導致決策失誤。
• 生產力下降：當資料發生問題時，資料和工程團隊都必須花費時間和精力來找出問題的根源，導致生產力下降。

為此，他們需要一個監控系統，即時偵測問題，避免憾事再度發生。

Uber 的監控系統：D3

為了解決這些資料品質問題，Uber 開發了一個名為 D3（Dataset Drift Detector） 的自動化系統，旨在監控和測量資料品質，以便及早發現並解決資料問題，避免對 Uber 的機器學習模型和業務決策造成負面影響。另外，由於 Uber 擁有上千個資料集，平均每個資料集有 50 多個欄位，這個 D3 監控系統也要有辦法承受如此龐大的資料量。

監控的指標

首先，為了觀察數據的變化趨勢，Uber 需要先訂定出 D3 監控系統需要觀測的指標，用以辨識數據是否發生問題。監控系統會持續計算這些統計數據，並與歷史數據和預期值進行比較，以找出數據中可能表示問題的變化。以下是 Uber 訂定出的觀測指標：

• 空值檢查：檢查資料集中，每個欄位資料是空值的百分比變化。
• Foreign Key (FK) Tests (cross-dataset column comparison)：用 FK 來檢查跨數據集的 entity 數量是否保持一致。
• 數值欄位的百分位數檢查：使用百分位數（例如：P50、P75、P99、P1）來檢查數值欄位的變化。
• 類別欄位的分布：檢查類別欄位中各個值的分布變化。

D3 的功能

制定好指標之後，Uber 開始打造 D3 自動化監控系統，他們希望有以下幾個功能：

• 自動化監控資料集：D3 會根據 offine 的使用，自動辨識出資料集中需要監控的重要欄位，並套用適當的監控指標，讓使用者不需要設定過多的 config。
• 多維度監控：D3 可以根據不同的維度（例如：應用程式版本、城市 ID）來監控數據變化，以便更精準地發現問題。
• 自動異常檢測（anomaly detection）：D3 使用機器學習模型來分析數據，並自動偵測異常情況，無需手動設定閾值。
• 提供可視化報表和警報： D3 會生成可視化報表，讓使用者可以直觀地了解資料品質狀況，並在偵測到異常情況時發送警報。

D3 的架構

接下來就要打造 D3 系統啦！D3 的架構主要包含三個部分：

1. 計算層 (Compute Layer)
2. 異常檢測 (Anomaly Detection)
3. 協調器 (Orchestrator)

1. 計算層 (Compute Layer)

計算層 (Compute Layer) 顧名思義，就是負責計算資料集的統計數據，並將其存儲到 Hive 表格中。計算層會執行兩種作業：

• 數據分析器 (Data Profiler)：這是一個一次性的作業，用於計算資料集過去 90 天的歷史欄位監控統計數據，這些數據將作為異常檢測模型的訓練資料。
• 每日排程作業：這個作業每天執行一次，用於計算資料集最新的欄位監控統計數據，並使用異常檢測算法來預測統計數據閾值，以及識別當天的欄位漂移。

計算層主要有以下幾個功能：

1. 支援多種資料指標：使用者可以自由新增新的指標，讓系統能夠適應不同的資料集和 use case。
2. 動態篩選資料：使用者可以在計算指標統計資料之前，先篩選出相關的資料，加速指標的計算。
3. 依據多種 dimension 以計算指標：D3 支援依據 dimension 來計算指標統計資料，讓使用者能夠深入分析特定資料區段的資料品質。舉例來說，如果 Uber 能夠監控特定城市的資料，那就可以及早發現他們喪失 10% 的美國關鍵地區資料，有助於他們及早發現問題。

由於 Uber 大規模的資料量，計算層也經過優化和調整，以確保效能和資源使用效率。例如，他們會將來自不同 scripts 中多個 SQL，組合成一組固定 script，以減少查詢數量。這項優化措施讓資源消耗量減少了 100 倍，每個資料集的平均計算成本從 1.5 美元降至 0.01 美元。

另外，對於每天資料量超過 1TB 的大型資料集，他們也會將資料集分成較小的區塊並行執行，以減少每個階段傳輸的資料量。

2. 異常檢測 (Anomaly Detection)

接著，為了滿足他們希望 D3 能夠自動偵測資料中的異常或偏差的功能，他們使用機器學習模型來偵測異常情況。若沒有這個自動檢測功能，需要藉由人為設定需要觀測的 SQL 和 threshold，但是這個方法需要人力持續地關注資料數值以及重新校準，才能適應不斷變化的資料趨勢。

D3 預設使用 Prophet 作為異常偵測模型。Prophet 是一種非線性迴歸模型，其效能優於移動平均等直觀技術，並且能夠自動調整以適應趨勢和季節性的變化。與其他異常偵測模型相比，Prophet 的優點是即使訓練資料量較少，也能有效運作。這個異常偵測模型的輸入是時間序列資料，並會輸出預測的指標值上限和下限，若超出上下限，則會發出警報。

另外，資料也很容易出現離群值和雜訊，為了避免誤報，D3 也會處理這兩類的資料：

• 離群值：D3 提供了一個「回饋」機制來處理離群值 (與大多數觀察值差異很大的資料點)。使用者可以手動將離群值標記為「真」或「假」，讓系統能夠從未來的預測中排除已知的異常資料點。
• 雜訊：對於本身就充滿雜訊 (出現許多峰值和谷值) 的時間序列資料，D3 會使用「診斷作業」來識別並過濾這些時間序列。系統會停用預測誤差百分比過高的指標警報，以減少誤報的發生。

3. 協調器 (Orchestrator)

D3 的第三部分是協調器 (orchestrator)，他的功能是作為 D3 與 Uber 其他數據平台之間的橋樑，負責將 D3 功能提供給其他平台使用，並管理 D3 的 metadata、監控指標、生命週期和資源。

1. Orchestrator 管理的 metadata：

每個資料集都包含維度、aggregators、支援的監控器類型、排除的欄位、資料集分割區相關資訊等 metadata。metadata 決定了哪些監控器可以定義在哪些資料集上，有助於前面提過的，讓 D3 可以自動辨識出資料集中需要監控的重要欄位，並套用適當的監控指標，讓使用者不需要設定過多的 config。

2. 生命週期管理：

Orchestrator 管理 D3 監控器的生命週期，包括分析資料、計算統計資料、異常偵測，以及更新 Uber 資料平台的狀態。另外，他也會讓 D3 與 dataset schema 變更保持同步，如果 metadata 發生變更（例如維度或 aggregator）或 monitor level attribute updates （例如 threshold or monitor type updates），則必須更新相應的監控器和統計資料。

3. Orchestrator 整合

最後，Uber 內部使用者都可以使用 D3，他們具有一個通用的 API 合約，讓任何系統都可以透過此合約進行整合，建立和維護資料品質測試及其生命週期。

D3 的優勢和未來發展

在介紹完 D3 的系統架構後，讓我們來看看 D3 為 Uber 帶來什麼好處吧！

D3 顯著地縮短問題偵測時間，讓 Uber 在資料問題發生後的 2 天內就偵測到，相比之前人工檢測需要 45 天，效率大幅提升。也因為及早發現和解決數據問題，D3 幫助 Uber 避免了數百萬美元的潛在營收損失。

具體來說，他們檢測到超過 6 個 production 環境上的問題，包含：

• 由於上游更動或錯誤的發布，關鍵欄位出現了空值。
• 由於資料來源損毀，關鍵欄位出現了空值。
• 數值欄位中出現了異常值的峰值。
• 每週被查詢約 13,000 次的資料集出現了資料遺失。

這些問題都會影響重大，因為這些欄位是用於推導關鍵指標、分析乘客行為以及計算乘客在應用程式上看到的車資。D3 的持續監控和警報功能可以幫助 Uber 確保數據的準確性和可靠性，從而提高決策的品質。

D3 的未來發展方向

Uber 計劃在未來繼續發展 D3 的功能，包括：

• 應用在機器學習模型的品質監控：除了資料集以外，Uber 也想要監控機器學習模型的特徵資料品質，以及訓練資料和線上資料之間的差異。
• 整合新的異常檢測算法：除了 Prophet 以外，Uber 也想要整合其他更先進的異常檢測算法，例如 ARIMA 等。

以上就是 Uber D3 監控系統的介紹啦！由他們的經驗可知，資料品質是非常重要的事，不僅會影響到模型表現，甚至會嚴重影響營收和商業決策判斷，因此我們在搜集數據時，勢必需要打造一個監控系統，確保資料都是完整的！

謝謝讀到最後的你，如果喜歡這系列，別忘了按下喜歡和訂閱，才不會錯過最新更新。
如果有任何問題想跟我聊聊，或是想看我分享的其他內容，也歡迎到我的 Instagram（@data.scientist.min） 逛逛！
我們明天見！

Reference

• https://www.uber.com/en-TW/blog/d3-an-automated-system-to-detect-data-drifts/